REMARKS 

Claims 1-12, 18-23, 25-26, and 30-31 are pending after this amendment. 
The remarks presented herein are in response to the Office Action dated July 
6, 2009. 



The Examiner rejected claims 1-12, 18-23, 25-26, and 30-31 under 35 USC 103 
as allegedly being unpatentable over Durham in view of Cui and Farber. This rejec- 
tion is respectfully traversed. 

Claim 1 recites: 



"A method for determining whether a client accepts visitor identifiers, comprising the 

steps of: 

a. ) receiving a request for a resource, the request originating at a client; 

b. ) determining whether the request for the resource includes a visitor iden- 

tifier; 

c. ) responsive to the request including a visitor identifier: 

obtaining data associated with the visitor identifier; 
determining that the client accepts visitor identifiers; and 
transmitting the requested resource to the client; 

d. ) responsive to the request not including a visitor identifier and responsive 

to the request not including an indicator that redirection has oc- 
curred: 

assigning a new visitor identifier; 

sending a redirection request with the new visitor identifier to the 
client, the redirection request including an indicator that re- 
direction has occurred; 

responsive to the client storing the new visitor identifier, determining 
that the client accepts visitor identifiers; 

responsive to the client not storing the new visitor identifier, deter- 
mining that the client does not accept visitor identifiers; and 

transmitting the requested resource to the client." 
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The claimed method determines whether a client accepts visitor identifiers. A 
request for a resource is received, for example at a server. The request originates at a 
client. A determination is made as to whether the request includes a visitor identifi- 
er. An example of such a visitor identifier is a cookie, although other types of visitor 
identifiers can be used. If the request includes a visitor identifier, data associated 
with the visitor identifier is obtained, a determination is made that the client accepts 
visitor identifiers, and the request is serviced by transmitting the requested resource 
to the client. 

If the request does not include a visitor identifier, and if the request does not 
include an indicator that redirection has already occurred, a new visitor identifier is 
assigned and a redirection request is sent to the client along with the new visitor 
identifier. The indicator, if present, ensures that the method does not send a redirec- 
tion request if redirection has already occurred; in this manner, the claimed method 
avoids an endless loop. 

If the client stores the new visitor identifier, a determination is made that the 
client accepts visitor identifiers. If the client does not store the new visitor identifier, 
a determination is made that the client does not accept visitor identifiers. The re- 
quest is serviced by transmitting the requested resource to the client. 

Claim 1 thus recites a method wherein, if a visitor identifier is found in the re- 
quest for the resource, the request can be processed without any further communica- 
tions from the client. Specifically, if the request includes a visitor identifier, data is 
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obtained, a determination is made that the client accepts visitor identifiers, and the 
requested resource is transmitted to the client. The method also includes an efficient 
mechanism for sending a redirection request in order to determine whether the client 
accepts visitor identifiers when the initial request does not include a visitor identifier. 
An indicator that redirection has occurred is included in the redirection request, so as 
to avoid repeated (and potentially endless) generation of new redirection requests 
when the client fails to return the visitor identifier in the next request. 



Claim 3 recites: 



"A method for determining whether a requestor accepts visitor identifiers, comprising the 

steps of: 

a. ) receiving a request for a resource from a requestor, the requestor having an ad- 

dress; 

b. ) determining whether the request includes a visitor identifier; 

c. ) responsive to the request including a visitor identifier: 

c.l) obtaining data associated with the visitor identifier; 

c.2) determining that the requestor accepts visitor identifiers; and 

c. 3) transmitting the requested resource to the requestor; and 

d. ) responsive to the request not including a visitor identifier: 

d. l) determining whether the request includes an indicator that step d.3) has 

been performed; 

d.2) responsive to the request including the indicator that step d.3) has been 
performed: 

assigning a visitor identifier from the requestor's address; 
determining that the requestor does not accept visitor identifiers; and 
transmitting the requested resource to the requestor; and 
d.3) responsive to the request not including the indicator that step d.3) has 
been performed: 

assigning a new visitor identifier; 

sending to the requestor a redirection request including the new visi- 
tor identifier and an indicator that step d.3) has been per- 
formed, the redirection request being adapted to cause the 
requestor to retransmit the request for the resource; and 

repeating steps a-d." 



Case OMN7132 



-15- 



Claim 3 recites a method wherein, if a visitor identifier is found in the request 
for the resource, the request can be processed without any further communications 
from the client. If the request does not include a visitor identifier, a determination is 
made as to whether the request includes an indicator that step d.3 has been per- 
formed, wherein step d.3 includes the assignment of a new visitor identifier and 
transmission of a redirection request. If the request includes an indicator that step 
d.3 has been performed, a determination is made that the requestor does not accept 
visitor identifiers; accordingly a visitor identifier is assigned from the requestor's ad- 
dress. If the request does not include an indicator that step d.3), then a new visitor 
identifier is assigned, and a redirection request is sent, including an indicator that 
step d.3 has been performed. Steps a-d are then repeated. 

Thus, both claims 1 and 3 specifically recite mechanisms by which an indicator 
is provided; the indicator specifies whether a redirection request has already been 
issued. In this manner, the claimed invention avoids transmitting repeated redirec- 
tion requests that might constitute an endless loop. This endless-loop avoidance me- 
chanism is a unique limitation that is not found in any of the cited references. 

Durham merely describes a technique for reducing browser latency by cach- 
ing a compressed representation of a core set of user information preferences. The 
Examiner cited a portion of Durham (col. 7, line 64 to col. 8, line 14 and Fig. 2, item 
100) that describes a test to determine whether a client sent a client cookie to the 
server, and that further describes retrieval of configuration information about the 



Case OMN7132 



-16- 



client. If the client did not send a cookie, or if the client is not found in the client da- 
tabase, a new database record is created and a new cookie is generated and sent to 
the client. These teachings constitute established, well-known uses of cookies to 
track users' usage of a website and to provide a personalized experience to visitors of 
a website. The test described in Durham is merely a check to see whether a cookie is 
present in the message sent from the client to the server. Durham does not describe a 
test to determine whether or not a client is accepting cookies or other visitor identifi- 
ers. Furthermore, nowhere in this cited portion of Durham, nor in any other portion 
of Durham, is there any mention of sending an indicator that redirection has oc- 
curred (which is referred to herein as a "do not repeat" indicator, for ease of nomen- 
clature but without any intention to limit the scope of the claimed invention). Nor is 
there any mention of determining whether such an indicator is included in a received 
request, so as to indicate that a visitor identifier has been assigned. 

The Examiner correctly states that Durham does not teach determining that 
the client accepts visitor identifiers, nor does it teach determining that the client does 
not accept visitor identifiers. Durham merely checks for the presence of a cookie; 
there is no teaching of any mechanism for determining whether or not a cookie has 
previously been set. In Durham, if the server does not detect a client cookie, it gene- 
rates a new cookie and sends it to the client. The server thus has no mechanism for 
determining whether the cookie is absent because it has never been set, or because 
the client is not accepting or storing cookies, or because the cookie has been deleted 
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at the client. Without a "do not repeat" indicator, the server of Durham might re- 
ceive multiple requests from a client that is not accepting cookies; in response, the 
server would repeatedly generate and transmit new cookies to the client without ev- 
er making the determination that the client is not accepting cookies. 

Cui does nothing to cure this deficiency of Durham. Cui merely describes a 
technique for removing cookies from web page response headers and storing the 
cookies in a repository for later use. A unique session ID is generated for a new ses- 
sion. As described in the portion of Cui cited by the Examiner (col. 1, lines 57-65), a 
proxy server checks a request header to determine whether the client's browser is 
capable of handling cookies. The request is handles differently depending on this 
determination. The proxy server then sends the request to the targeted external web 
site to get the corresponding page. The proxy server strips off any cookies set by the 
external web site from the response header, and stores the cookies in a repository for 
subsequent requests within the session. 

Nowhere in Cui is there any mention of an indicator that redirection has oc- 
curred (i.e., a "do not repeat" indicator). Cui's description that the proxy server 
"checks the request header to determine whether the browser of the client is capable 
of handling cookies" provides no hint or suggestion of a "do not repeat" indicator for 
use in making such a determination. In fact, Cui's description assumes that the de- 
termination as to whether the browser can handle cookies can be made by checking 
the request header. Such a description actually teaches away from the invention 
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claimed herein: if the determination can be made by checking the request header, Cui 
has no need for any indicator that redirection has occurred as recited herein. Accor- 
dingly, the combination of Durham and Cui still fails to teach or suggest the claimed 
method. 

The Examiner correctly states that the Durham-Cui combination does not 
teach responsive to the request not including an indicator that redirection has oc- 
curred, assigning a new visitor identifier. The Examiner states that Farber provides 
such a teaching. 

To the contrary, Farber fails to teach the use of an indicator that redirection 
has occurred as recited herein. Farber merely describes techniques for intercepting 
resource requests from clients, and selectively reflecting such requests to repeaters. 
When a reflector or repeater serves a resource which includes resource identifiers, 
the resource is modified to "pre-reflect" resource identifiers. This is to ensure that 
requests go to the proper place; when a browser requests repeatable resources identi- 
fied by the requested resource, it gets them from a repeater without going back to the 
origin server; however, when the browser requests non-repeatable resources, the re- 
quest goes to the origin server. This modification thus improves efficiency by avoid- 
ing extraneous redirections, as described at column 16, lines 27-45. 

Although Farber uses some terminology that may appear to resemble the lan- 
guage of the present claims, the method claimed herein is entirely distinct from that 
described in Ferber. Specifically, the cited portion of Farber merely describes mod- 
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ifying a resource to pre-reflect resource identifiers in the resource. This modification 
is in no way equivalent to the indicator that redirection has occurred recited in the 
present claims. Rather, Farber's modification is performed to improve the efficiency 
of subsequent requests for resources, while the present claims recite the use of the 
indicator that redirection has occurred in order to determine whether or not to assign 
a new visitor identifier. In the present claims, a new visitor identifier is assigned and 
a redirection request is sent in response to absence of the indicator that redirection 
has occurred. Thus, the claims presented herein do not merely recite an indicator 
that redirection has occurred, but they also recite particular steps to be performed 
responsive to the absence of the indicator. These steps are not found in any of the 
cited references. 

The Examiner also cited Fig. 3 of Farber, in which an element reads "reply is 
redirect?" However, neither this Figure nor the explanatory text in Farber describes 
the specific steps recited in the present claims. Rather, this element of Farber refers 
to a different technique entirely. In Farber, instead of providing a client with a re- 
source, an origin server can tell a client to re-request the resource by another name. 
To do so, the server sends the client a reply called a "REDIRECT" which contains a 
new URL indicating the other name. The client then repeats the request sequence, 
this time requesting the resource identified by the new URL. Thus, in Fig. 3, if the 
reply is a "REDIRECT", the next step is to return to the beginning of the process with 
a new URL. See col. 7, lines 27-35. 
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The "reply is redirect?" therefore serves an entirely different purpose, and op- 
erates in an entirely different manner, than described in the method claimed herein. 
In Farber, a redirection request tells a client to re-request a resource by another name. 
Rather, in the method claimed herein, the redirection request is sent to the client with 
a new visitor identifier, as part of the process for determining whether the client ac- 
cepts visitor identifiers. Accordingly, the redirection request with the new visitor 
identifier is sent to the client in response to a specific set of circumstances, as explicit- 
ly set forth in the claims: the redirection request is sent responsive to the received re- 
quest not including a visitor identifier and not including an indicator that redirection 
has occurred. The claimed method thus recites much more than the simple existence 
of a redirection request, but rather describes a specific methodology and context for 
sending a redirection request responsive to certain specified conditions, none of 
which can be found in Farber. Furthermore, as discussed above, the claimed method 
includes an indicator that redirection has occurred, so that subsequent request han- 
dling does not result in an infinite loop. 

Claim 3 recites additional specific steps that are not found in the cited refer- 
ences. For example, claim 3 recites a specific step to be performed in response to a 
request including an indicator that step d.3 has been performed: a visitor identifier is 
assigned from the requestor's address. This step facilitates visitor tracking even in 
situations where it has been determined that a requestor is not accepting visitor iden- 
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tifiers. For example, if a client is not accepting or storing cookies, the requestor's ad- 
dress is used as the basis for a visitor identifier that can be used in lieu of cookies. 

Nowhere in any of the references is there any hint or suggestion of such a step. 
The Examiner cited column 7, line 64 to column 8, line 14 of Durham, along with Fig. 
2, item 112 of Durham, as teaching this limitation. However, the cited text merely 
describes determining whether a client sent a cookie, and retrieving configuration 
information from a database. If the test fails, a new cookie is initialized and sent. 
However, there is no mention of assigning a visitor identifier from the requestor's 
address as claimed herein. Fig. 2, item 112, merely reads "Create Server Record" and 
again fails to describe assigning a visitor identifier from the requestor's address as 
claimed herein. 

Accordingly, none of the cited references, taken alone or in any combination, 
teach or suggest the specific elements recited in the present claims. Specifically, none 
of the cited references teach or suggest the use of an indicator that redirection has oc- 
curred in the manner claimed herein. 

Accordingly, claims 1 and 3 are respectfully submitted to be patentable over 
the cited references, taken alone or in any combination. 

Claim 11 recites a data collection server and includes limitations similar to 
those discussed in connection with claim 3. Claim 18 recites a computer program 
product including limitations similar to those discussed in connection with claim 1. 
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Claim 19 recites a computer program product including limitations similar to those 
discussed in connection with claim 3. Claims 2, 4-10, 12, 20-23, 25-26, and 30-31 va- 
riously depend from claims 1, 3, 11, and 19 and incorporate the limitations discussed 
above. Accordingly, claims 1-12, 18-23, 25-26, and 30-31 are hereby submitted to be 
patentable over the cited references, taken alone or in any combination. 



On the basis of the above remarks, consideration of this application and the 
early allowance of all claims herein are requested. 

Should the Examiner wish to discuss the above remarks, or if the Examiner be- 
lieves that for any reason direct contact with Applicants' representative would help 
to advance the prosecution of this case to finality, the Examiner is invited to tele- 
phone the undersigned at the number given below. 

Respectfully submitted, 
Brett Error, et al. 



Dated: September 3, 2009 By: / Amir H. Raubvogel/ 

Amir H. Raubvogel 
Reg. No. 37,070 
Raubvogel Law Office 
820 Lakeview Way 
Redwood City, CA 94062 
Phone: (650) 209-4884 
Fax: (650) 362-1800 
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